Software-defined networking is an emerging architecture for data transfer networks. In a software-defined network “SDN”, the control-plane is separated from the data-plane so that the control-plane is implemented in a controller system that can be separate from the data forwarding network elements and the data-plane is implemented in the data forwarding network elements. Typically, the software-defined networking allows for quick experimenting and optimization of switching and/or routing policies and external access to the innards of data forwarding network elements that formerly were closed and proprietary. The data forwarding network elements can be, for example, Internet Protocol “IP” routers, multiprotocol label switching “MPLS” nodes, packet optical switches, and/or Ethernet switches. Each data forwarding network element may consist of a single apparatus or a combination of a plurality of apparatuses. Furthermore, a data forwarding network element can be a software-implemented virtual machine “VM” running in a hardware that has other tasks too.
The controller system of a software-defined network “SDN” is adapted to configure the data forwarding network elements so that the data forwarding network elements are capable of operating as nodes of the software-defined network. When configuring a data forwarding network element, the controller system sends to the data forwarding network element configuration data with the aid of which the data forwarding network element constructs a data-plane system for forwarding and otherwise managing data. The data-plane system comprises typically one or more look-up tables with the aid of which the data forwarding network element is capable of operating as a part of the software-defined network. The data-plane system can be constructed and maintained in accordance with for example the OpenFlow protocol. Details about the OpenFlow can be found from the OpenFlow Switch Specification managed by the Open Networking Foundation “ONF”.
The architecture of the controller system has evolved from the original centralized-controller architecture where the controller system is implemented with a single controller entity to a multi-controller architecture where the controller system is implemented with many controller entities that are located in a distributed way in the software-defined network, because the original centralized-controller architecture has its limits on the scalability and it is more vulnerable than the multi-controller architecture. Each controller entity may consist of a single apparatus or a combination of a plurality of apparatuses, or a controller entity can be a software-implemented virtual machine “VM” running in a hardware that has also one or more other tasks such as, for example but not necessarily, operating as a data forwarding network element. It is also possible that a same hardware is used for two or more functionally separate controller entities so that each of the controller entities is a software-implemented virtual machine.
The multi-controller architecture is, however, not free from challenges. One of the challenges is related to the requirement to ensure that the control-plane is implemented in the decentralized controller entities so that different ones of the controller entities do not, in any situation, deliver mutually conflicting configuration messages to the data forwarding network elements.